Field of the Invention
Exemplary embodiments of the present invention are directed to a method and system for managing compliance/assurance and security requirements in reusable models, and for demonstrating the traceable correspondence between those requirements and effective security implementation across the information technology (IT) system. The present invention can define, edit, merge and process requirement models; can collect, analyze and document IT system and security evidence; and can analyze evidence about changes to an IT system and its security; and can provide decision support to humans. The invention also facilitates the automation of a large part of what is known in the industry as an evaluation/accreditation or compliance management process. Embodiments of the invention are also relevant for IT systems that are dynamically evolving over a system lifecycle, which can be referred to as “agile” IT systems.
Description of the Related Art
Conventional security and compliance accreditation of IT systems (typically called “Target of Evaluation”, TOE) currently involves a human security evaluator who documents evidence and verifies whether the IT system is in line with the requirements (typically called “Security Target”, ST) by using different methods, for example, by testing or formal analysis.
The security requirements for example state that all data communication has to be protected for integrity (no modification of data) and confidentiality (no disclosure of data). The human evaluator then checks whether the system really meets these requirements, for example whether the communication is encrypted and whether a so-called hash function is applied, which provide confidentiality and integrity of communication, respectively.
The following exemplary analogy helps to understand this evaluation process: the construction of a house is based on a set of blueprints describing specific aspects of the house, for example the walls, doors and windows, or its electrical or heating system. These blueprints are models of specific aspects of the house. The blueprints use specific symbols known to one skilled in the art, for example an architect or electrician, such that the person is able to understand their meaning. For different aspects, specific sets of symbols are used, for example the architect and the electrician use different sets of symbols.
Model Driven Software Engineering (MDE) uses a similar approach. Specific sets of symbols, here called Domain Specific Languages (DSLs), are used to describe (instead of symbols for doors and windows) the parts of a software system as models, for example, of functional aspects like data formats, services, interfaces, interactions or sequences of actions. Unlike civil engineering, in MDE it is possible to directly generate large parts of the IT systems from the models, for example source code and configuration files. Similarly, it is possible to generate security enforcement from security models (using Model Driven Security, which is described further below). This ensures, to speak in terms of the analogy, that the building exactly matches the blueprints and that it is sufficient to analyze the blueprints in order to evaluate that the building meets a specific criteria.
Model Driven Security (MDS) as described in U.S. patent application Ser. No. 12/126,711, which is incorporated herein by reference, is directed to the automatic generation of machine enforceable security rules from security policies expressed close to human thinking (i.e. which are potentially not machine enforceable). MDS applies the concepts of MDE to security. Using MDE, there is a high probability that IT systems match the functional models. Similarly, using MDS, there is a high probability that IT systems security matches the security models.
Both houses and IT systems have to comply with specific requirements and legal regulations, which depend on many factors. For example, a house that is built in an area with a high risk of earthquakes needs to be built in a stronger way than a house built in an area with a low risk of earthquakes.
In the state of the art of IT compliance, these security and compliance regulations are described in a informal text, which cannot be processed by an IT system. A human evaluator therefore has to (manually) verify whether the IT system (or a house in the analogy) is in line with the security and compliance requirements. This is of course a difficult and error prone process that requires a lot of human effort.
A conventional process for evaluating correspondence between the IT system security and the security requirements (i.e. the security and compliance evaluation/accreditation/compliance process) involves significant manual effort (i.e. no automation), and the probability that the accreditation matches the operational IT system security is low or unclear. This is because the manual evaluation process does not tie into automated, verifiable processes such as Model Driven Software Engineering (MDE) and/or Model Driven Security (MDS).
Today there are many DSLs to describe systems, e.g. file formats of different Computer Aided Design (CAD) programs, or country or profession specific sets of symbols used for a construction of a house, or different modeling languages for IT systems, such as UML, SysML or BPMN. In the conventional art, security related information for security enforcement is added directly into these specific functional DSLs (e.g. as annotations in functional models or as compliance policies expressed in the terms of a specific functional DSL). Unfortunately this greatly limits the reuse of compliance, security and accreditation polices, because the security related information is then always bound to a specific DSL and model.
Both IT systems and buildings (in the analogy) are typically changed over their life cycle. Then, except in simple cases already foreseen and planned for in the initial accreditation, it is necessary to “re-accredit” the systems, i.e. to check whether particular changes impact the compliance accreditation or not. For example, if important electrical equipment such as an air conditioning system has to be replaced in a building, then this potentially impacts the accreditation of the building as a whole. The new equipment might have a higher weight and a higher consumption of energy. It is necessary to verify that the building is still able to provide the required functionality, e.g. whether the weight of the new equipment is a risk to the statics of the building or whether enough electrical power can be provided. However, in the case where the new equipment is, from a compliance and accreditation point of view, equivalent to the old equipment, then a full re-accreditation is not required. Conventionally, this has to be manually verified, e.g. by comparing the data sheets of the new equipment.
The analogy and discussion so far illustrate the important concept that information security is not only about implementing security across IT systems and applications according to security requirements. It is often also necessary to demonstrate the level of confidence that IT system security complies with the stated security requirements. This is called “compliance” or “information assurance” (and involves “evaluation” and “accreditation” processes).
Civilian and government compliance examples include best practices, laws and regulations, e.g. ITILv3/ISO2700x, ISMS, COBIT for security management; privacy legislation, healthcare legislation such as HIPAA, payment card processing such as PCI, safety standards and regulations such as ISO 26262, DO 178B or EN50128 for safety, accounting/auditing regulations such as Sarbanes-Oxley.
More rigorous government information assurance examples include the “Common Criteria” (CC) standard ISO/IEC 15408, a framework in which computer system users can specify their security requirements, vendors can then implement and/or make claims about the security attributes of their products, and testing laboratories can evaluate the products to determine if they actually meet the claims. In other words, CC provides assurance that the process of specification, implementation and evaluation of a computer security product has been conducted in a rigorous and standard compliant manner. Common Criteria evaluations are performed by “accredited” human evaluators and organizations. Evaluations are performed on computer security products and systems called “Target Of Evaluation” (TOE). The “evaluation” serves to verify claims made about the target's security features. This is commonly done through a manual process that involves a number of documents: (1) A “Protection Profile” (PP) identifies security requirements for a class of security devices; (2) A “Security Target” (ST) identifies the security properties of the TOE. It may refer to one or more PPs. The TOE is evaluated against the SFRs and SARs (see below) established in its ST, no more and no less. This allows vendors to tailor the evaluation to accurately match the intended capabilities of their product. (3) “Security Functional Requirements” (SFRs) specify individual security functions which may be required by a product, e.g. authentication or access control. (4) “Security Assurance Requirements” (SARs) -descriptions of the measures taken during development and evaluation of the product to assure that the claimed security functionality works as intended. The evaluation process tries to establish the level of confidence that may be placed in the product's security features through quality assurance processes; (5) “Evaluation Assurance Level” (EAL)-the numerical rating EAL1-EAL7 describing the depth and rigor of an evaluation. Higher EALs do not necessarily imply “better security”, they only mean that the claimed security functionality of the TOE has been more extensively validated.
Today's compliance/security assurance methods were originally developed to accredit the security of static complete (i.e. siloed, monolithic) systems which may be reconfigured within certain and well as defined limits, but do not change in unforeseen ways. However, today's IT architectures support agile interconnected networked (“distributed”) applications to meet changing business demands and evolve over the whole system life time. Example architectures include Service Oriented Architecture (SOA), Web 2.0 and mash-ups, Cloud Computing, SaaS/PaaS, Grid Computing. Examples for agile application development include model-driven, process-led software development and integration (e.g. Model Driven Architecture (MDA), Model Driven Software Engineering (MDE), and executable Business Process Management (BPM). An example of an agile application aspect is application interactions, such as SOA service interactions and BPM interactions.
Security methods and systems are typically important for such IT architectures and also need to support agility. There are many efforts to use model-driven approaches for non-functional system aspects to improve for example (1) the safety and security of systems, e.g. using the abovementioned Model Driven Security (MDS) for agile security policy management, (2) the assessment of risks, (3) evaluation and accreditation, and (4) compliance with legal and regulatory requirements.
Conventional compliance/security/accreditation methods fail for such dynamically changing (“agile”) IT systems. This is because changes may impact the security properties of the system in such a way that the system does not comply with the required level of compliance/assurance anymore. In such a case it is necessary to “re-accredit”, i.e. to analyze (i.e. “re-evaluate”) the impact of the changes and potentially mandate updates to the IT systems. Today, this is a time-consuming, manual process which is not sufficiently fast and cheap to support the agility of today's IT systems.
Particularly time-consuming manual, paper-based compliance/security processes include:
(1) Documenting and processing compliance/security requirements. Even if a model-driven approach to development and security is used, compliance related information is conventionally simply tagged to the related model elements in the functional model itself. This has several disadvantages: Compliance information is not described generalized, application/platform independent. Instead it has to be described as a single, large model at the low abstraction layer of the functional system model and bound to a specific application, and it is not possible to easily associate specific sets of model elements (e.g. “All information flow”) with a given compliance element (e.g. “All information flow over public network has to be protected”), or associate/aggregate model elements describing accreditation related information;
(2) Collecting, documenting compliance/security evidence in a timely, correct, and consolidated fashion;
(3) Analyzing compliance/security evidence to identify whether the IT system and its IT security meet the documented requirements. This has to be one initially, and again after each unforeseen change to the IT system and its security; and/or
(4) Manual corrections may be necessary if the analysis identifies that the compliance/security requirements are not met (e.g. to the IT system, the security, the compliance/security requirements).